A methodology is basically a set of procedures for gathering requirements, analyzing and (sometimes) designing a program. Most methodologies are associated with a form of graphical notation and with several types of charts used to illustrate different aspects of a program. Methodologies are, for the most part, language and hardware independent, but have traditionally been more occupied with the functions of a program than its data. In the last few years, a number of object oriented methodologies have hit the marketplace, claiming to mesh better with object oriented languages such as C++ and Smalltalk than the old fashioned methodologies do.

Why use a methodology? Many programmers, and the organizations that employ them, are impatient with the requirements and analysis phase of a project and handle it casually, or not at all, plunging directly into coding. Frequently, the result is either that the program does not match the user's requirements, or that the requirements gathering, analysis, design and coding are all happening simultaneously--an expensive, sloppy and potentially disastrous way to build software.

A methodology is a way of enforcing self-discipline and ensuring a rigorous and thorough analysis of the problem at hand. It also acts as a check-list making sure nothing has been missed. Finally, since information is usually displayed in a graphic format, problems and concerns may become more easily apparent than they would be from reading an old-fashioned, "Victorian novel" text specification.

Why use an object oriented methodology? If you are going to be working in an object oriented language such as C++ or Smalltalk, you risk losing much of the flexibility and function of these languages, such as inheritance, encapsulation and polymorphism, if you do not start taking these features into account at the analysis and design phase. If you use a traditional methodology, you may wind up with a program that does not truly make use of OO concepts, even though written in an object oriented language.

I evaluated four of the leading OO methodologies: Booch, Coad-Yourdon, Rumbaugh and Shlaer-Mellor. Although others exist, we selected these four for the following reasons:

Each methodology is published and supported by a company committed to improving it, and available to consult and train in its implementation.
Each is supported by one or more CASE tools.
Each is explained in a currently available book written by the creator of the methodology.
Each has gained some commercial acceptance.

We used the following criteria for evaluation:

Is the methodology simple enough to explain to an end user, even a relatively non-technical one?
Does it support both the analysis and design phases of the project?
Is it powerful enough to support detailed design of the software?
How many different types of charts are supported or required?

Booch -is a design rather than an analysis methodology, better suited to the nuts and bolt issues than to the initial gathering of requirements. By reason of its power and complexity, Booch and its associated charts would be difficult to explain to a nontechnical end user.

Coad-Yourdon - support analysis much more strongly than design. Coad-Yourdon tries to model entire systems in one form of chart, showing classes, objects, their attributes and services, and their interrelationships. This chart will not be difficult to grasp for anyone who has done Entity-Relationship diagramming in database design, and seemed easiest, of all the four methodologies, to explain to a nontechnical end user. (Coad-Yourdon also endorses the use of state transition diagramming for real time systems but pays this approach much less attention than some of its competitors.)
Message connections between objects are shown on the same chart, whereas other methodologies seem to prefer to handle program functions in a separate diagram. At the analysis phase, and especially when communicating with an end user, there is a lot to be said for representing as much as possible, as clearly as possible, in a single type of diagram.

Rumbaugh - supports three types of charts, Object, Dynamic and Functional.
The dynamic chart is our old friend the state transition diagram.
The functional chart is the dreaded data flow diagram that some of the other methodologies seem proud to have left behind with the "old-fashioned" approaches.
The object chart is quite similar to Coad's, but does not handle message connections between objects, so that the Object and Functional diagrams, at a minimum, must be read together to understand the system.

Shlaer-Mellor - supports object, state transition and data flow diagrams. Like the others, except for Coad-Yourdon, message connections are not handled on the object chart.
The object chart is fairly similar again to entity relationship diagramming and the Coad and Rumbaugh charts.

In the end, which methodology you use may be less important than that you are using one at all. Any of these approaches will help organize your thoughts and coordinate your attack on the "problem domain".